app/services/jobs/shared-steps.server.ts (1)

196-199: busy イベントのログ出力レベルについて確認してください。

SQLite busy イベントが発生した場合、step.log.warn で警告として出力されています。これはオペレーターへの通知として適切ですが、gaveUp イベントが含まれる場合は、より深刻な問題を示している可能性があります。

gaveUp が 0 より大きい場合は error レベルでログ出力することを検討してください。

♻️ gaveUp がある場合は error レベルで出力する提案

   const busySummary = summarizeBusyEvents(sqliteBusyEvents)
   if (busySummary) {
-    step.log.warn(busySummary)
+    const hasGaveUp = sqliteBusyEvents.some((e) => e.gaveUp)
+    if (hasGaveUp) {
+      step.log.error(busySummary)
+    } else {
+      step.log.warn(busySummary)
+    }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/services/jobs/shared-steps.server.ts` around lines 196 - 199, The current
code logs the summarized busy events with step.log.warn unconditionally; update
the handling after calling summarizeBusyEvents(sqliteBusyEvents) so that if the
returned busySummary indicates gaveUp > 0 (inspect busySummary.gaveUp) you call
step.log.error with the busySummary, otherwise keep step.log.warn; ensure you
still only log when busySummary is truthy and reference the
summarizeBusyEvents/sqliteBusyEvents variables and the step.log.warn/error calls
when making the change.

app/services/jobs/backfill.server.ts (1)

37-42: リポジトリ単位のエラーハンドリングを検討してください。

現在の実装では、1つのリポジトリで backfillRepo が失敗すると、ジョブ全体が停止します。他のリポジトリの処理を継続し、失敗したリポジトリのみを後で再試行できるようにする方が、大規模な組織では有用かもしれません。

Durably がステップ失敗時にリトライするため、現在の設計でも問題ありませんが、部分的な成功を許容するかどうかは要件次第です。

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/services/jobs/backfill.server.ts` around lines 37 - 42, Wrap the per-repo
call to backfillRepo inside the step.run callback with a try/catch so a failure
for one repository doesn't bubble out and stop the whole job: inside the loop
that calls step.run(`backfill:${repoLabel}`...) catch any error from
backfillRepo(repository, ...) and log it with the repoLabel and error details,
push the repository identifier into a failedRepos array declared outside the
loop for later retries, and do not rethrow so the loop continues; optionally,
after the loop finishes, check failedRepos and decide whether to surface a
job-level error or schedule retries.